Enterprises are increasingly generating reports to characterize their business and scientific data. Often, these reports include data arranged according to a pre-defined design template. The creation of such reports is referred to as “formatted reporting.”
Typical report designs, for example a balance sheet, contain pages with a list of detail rows, a header row on top, and a footer row at the bottom. With such reports, there is usually no need to define the design of each and every detail row. It is sufficient to define the design of just one detail row for a report renderer (e.g., software that produces the final report, for example in HTML- or PDF-format) to apply automatically once to every detail data row during rendering.
When generating a report design, those portions of a report which are to be rendered in an appearance different from other portions of a report must be defined. For example, a report design (also referred to herein as a design) may define that rows containing revenues of a company's French subsidiaries are to be rendered with green background color while all other subsidiaries are rendered with a white background color.
Reporting software packages permit the generation of a design in which conditions may be attached thereto. Only when the attached condition holds during rendering is the report rendered using a format defined by the design. One example is a “zebra” pattern report template in which every odd report detail row is to be rendered with a light blue background and every even report detail row is to be rendered with a dark blue background.
In design tools of reporting software packages, conditions have conventionally been expressed in a proprietary non-markup language. However, reporting software packages are increasingly moving from an arrangement in which designs are stored in proprietary binary format to an arrangement in which designs are stored in textual formats with content expressed in a markup language (such as XML (eXtensible Markup Language)). With the textual format, stored content, which is expressed in a markup language, may be read and understood by a user. In contrast, proprietary binary content cannot be deciphered by users. Moreover, the structure of content expressed in a markup language can be defined by a grammar (see, for example, DTD (Document Type Definition), XML Schema, etc.). By applying such a grammar to content by readily available software tools (Validating XML Parser), the content can be easily checked for syntactical correctness and integrity.
Reporting software packages that permit conditional formatting generally fall in two categories: they either store the design and the conditions in a proprietary, binary format or store the design in a markup language with the conditions embedded into the markup as string literals of an non-markup language (e.g., Java, etc.). While these reporting software packages offer a high degree of flexibility in the final appearance of a rendered report through the use of complicated conditions, such packages as well as rendered reports with faulty visualizations are often difficult to debug and/or require specialized parsing tools which are costly to develop and increase processing times and resource consumption.